Event Camera Benchmarking on NVIDIA Jetson
Introduction
This page documents the latency benchmarking of the Prophesee GenX320 event-based sensor running on an NVIDIA Jetson Orin NX platform with JetPack 6.2.1 and driver version v0.1.0.
The goal of this benchmark is to measure end-to-end latency from a physical stimulus (LED activation) to its detection in software. Different streaming configurations (transport-frame timing and buffer dimensions) are evaluated to understand their impact on latency.
Measurement Setup
To obtain accurate and reproducible latency measurements, the following controlled setup was used:
- The sensor was placed inside a closed enclosure containing only a single LED.
- The enclosure ensures that no external light sources generate spurious events, making the LED the only source of activity.
Measurement Methodology
- A test application turns the LED ON and records a timestamp using the TSC (Time Stamp Counter). This timestamp is referred to as t0.
- The software continuously reads buffers from the driver and counts the number of events per buffer.
- Since the scene is static, any significant increase in the number of events indicates a change caused by the LED turning ON or OFF.
- When the number of events exceeds a predefined threshold, the LED transition is considered detected, and a second timestamp t1 is recorded.
- The latency is computed as:
- Latency = t1 - t0
This procedure was repeated 10 times for each configuration, and the average latency was computed.
Driver Configuration
The driver supports:
- Variable and fixed frame size streaming modes
- Configurable buffer width and height
- Configurable frame period
For these tests, the variable mode was used with different configurations depending on the target frame rate.
Here, FPS refers to transport frames per second, not conventional image frames. The dimensions below describe transport buffers, not the GENX320 sensor's 320×320 pixel resolution.
Results
100 FPS (4096×391 transport buffer)
Driver Configuration
#define GENX320_TRANSPORT_MODE "variable" #define GENX320_TRANSPORT_PACKET_SIZE 4096 #define GENX320_TRANSPORT_FRAME_SIZE 391 #define GENX320_TRANSPORT_WINDOW_US 10000
| Run | Latency (ms) |
|---|---|
| 1 | 9.087168 |
| 2 | 9.235584 |
| 3 | 9.254272 |
| 4 | 9.276032 |
| 5 | 9.236672 |
| 6 | 9.287712 |
| 7 | 9.200384 |
| 8 | 9.236928 |
| 9 | 9.240672 |
| 10 | 9.304736 |
| Average | 9.236016 |
500 FPS (4096×391 transport buffer)
Driver Configuration
#define GENX320_TRANSPORT_MODE "variable" #define GENX320_TRANSPORT_PACKET_SIZE 4096 #define GENX320_TRANSPORT_FRAME_SIZE 391 #define GENX320_TRANSPORT_WINDOW_US 2000
| Run | Latency (ms) |
|---|---|
| 1 | 3.634240 |
| 2 | 3.655680 |
| 3 | 1.669664 |
| 4 | 3.631840 |
| 5 | 3.695136 |
| 6 | 3.710016 |
| 7 | 3.689472 |
| 8 | 3.682400 |
| 9 | 1.705376 |
| 10 | 3.693696 |
| Average | 3.276752 |
1000 FPS — approximately 1 kHz (1024×32 transport buffer)
The configured 1008 µs frame window corresponds to a nominal transport cadence of approximately 992 Hz, rounded here to 1000 FPS.
Driver Configuration
#define GENX320_TRANSPORT_MODE "variable" #define GENX320_TRANSPORT_PACKET_SIZE 1024 #define GENX320_TRANSPORT_FRAME_SIZE 32 #define GENX320_TRANSPORT_WINDOW_US 1008
| Run | Latency (ms) |
|---|---|
| 1 | 2.547680 |
| 2 | 2.560480 |
| 3 | 2.566528 |
| 4 | 2.591328 |
| 5 | 2.539584 |
| 6 | 2.540864 |
| 7 | 2.536064 |
| 8 | 2.562976 |
| 9 | 2.599968 |
| 10 | 2.543776 |
| Average | 2.558925 |
Summary
The results show that latency decreases as the transport-frame rate increases and transport-buffer dimensions are reduced. This behavior aligns with expectations, as smaller buffers and higher transport-frame rates reduce the time required for event accumulation and processing.
These measurements provide a baseline for evaluating driver performance and can be used to guide configuration choices depending on latency requirements.